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Data Authentication and Provisioning Method and System 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims priority of U.S. provisional patent application Nos. 60/410,032 
and 60/469,284, filed September 10, 2002 and May 9, 2003, respectively, both entitled 
"Profile and Identity Authentication Services," which are hereby incorporated by reference. 

This application is related to U.S. Patent Application No. 10/370,149 (Attorney Docket 
No. VISAP070), filed February 19, 2003, entitled "Mobile Account Authentication Service," 
which claims priority of U.S. provisional patent application nos. 60/373,702 and 60/405,869, 
filed on April 17, 2002 and August 23, 2002, respectively. 

This application is related to U.S. patent application No. 10/156,271, filed May 24, 
2002, and entitled "ONLINE ACCOUNT AUTHENTICATION SERVICE," which is a 
continuation-in-part to U.S. Patent Application No. 09/842,313 filed April 24, 2001, entitled 
"On-Line Payer Authentication Service," which in turn claims priority of U.S. provisional 
patent application No. 60/199,727, filed April 24, 2000 entitled "Visa Payer Authentication 
Service Description," all of which are hereby incorporated by reference. 

FIELD OF THE INVENTION 

The present invention relates generally to online transactions, and more specifically to 
20 techniques for authenticating and/or providing the identity and profile data of a presenter. 

BACKGROUND OF THE INVENTION 

During a transaction between two parties, each party typically wants assurance as to 
the authenticity of the identity and/or the data relating to the other party so to avoid a variety 

25 of problems, one of which is fraud. Such transactions can be either payment or non-payment 
in nature. In non-payment transactions, for example, one party may want to confirm the 
identity of the other party before disclosing certain information. On the other hand, during a 
payment transaction using a payment card (e.g., a credit, debit, or stored value card), it is 
important to verify a user's ownership of an account to avoid unauthorized use of the payment 

30 card. 
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Authentication procedures during transactions when two parties are interacting in each 
other's physical presence (referred to as "in-person" transactions) can involve verifying that 
the signature of a user matches the signature on an identification or a payment card. Another 
authentication procedure involves verifying that a photograph contained in a form of 
5 identification matches the physical appearance of the user. 

However, online transactions are riskier because the "in-person" authentication 
procedures cannot be performed. Online transactions can be conducted through mediums 
such as but not limited to computers, mobile devices, telephones, or interactive television. 
Given the continued expected growth of electronic transactions, it is important to provide 

10 methods to authenticate the identity and profile data of individuals. Authentication techniques 
during online transactions will reduce the levels of fraud and disputes, which in turn will 
reduce the costs associated with each of these events. Prior systems used to authenticate users 
during online transactions have not been widely adopted because these systems were difficult 
to use, had complex designs, required significant up-front investment by system participants 

15 and lacked interoperability. Certain prior systems additionally required the creation, 
distribution and use of certificates by various entities involved in a transaction. Such use of 
certificates is known to be quite burdensome. 

Current systems for authenticating the identity and/or the profile data of individuals 
online for non-payment transactions use existing databases of information to determine a 

20 likelihood that profile data entered by an individual is authentic. These systems operate by 
asking specific factual questions of which only a limited number of parties would know the 
answer. For example, such systems may ask for the exact amount of the presenter's latest 
payment for a specific bill (e.g., a mortgage payment). Such a question could also inquire 
about the last two digits of such a payment, rather than the entire amount. Using such 

25 questions, these service providers are able to determine the likelihood (e.g., a numerical 
percentage) that the actual individual provided the correct answers. Correct answers do not 
lead to a definitive indication that the actual individual entered the correct answer because the 
possibility exists that an imposter made a lucky guess as to the answer or that an imposter 
discovered the correct answer through secretive investigation. Unfortunately because of these 

30 possibilities, the current systems cannot provide definite indication as to authenticity of profile 
data. For example, Equifax (see www.econsumer.equifax.com) and Experion Systems (see 
www.experionsvstems.com) provide such services. 
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In view of the foregoing, a system for authenticating the identity and profile data of an 
individual during an online transaction would be desirable. Such an authenticating system 
should be relatively easy to implement and use, require a minimal investment of resources, 
and provide a high level of interoperability between the system's participants. 
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BRIEF SUMMARY OF THE INVENTION 

The present invention provides methods and systems for authenticating the identity 
and validating the profile data of an individual ("a presenter") who presents him or herself to 
another party ("an acceptor") as having a certain identity and having certain corresponding 
5 profile data. The invention can be advantageously used in Internet transactions where such 
authentication is difficult to perform. The techniques of the present invention allow the 
trusted party to give a definitive answer regarding the authentication of identity and profile 
data. Other capabilities such as profile data provisioning and profile updating can also be 
performed. 

10 One aspect of the present invention pertains to a method for validating the profile data 

of the presenter during an on-line transaction. This method involves receiving profile data at 
the trusted party, comparing the profile data against reference data stored by the trusted party, 
notifying the acceptor by the trusted party that the profile data of the presenter is either 
authentic or erroneous. In one embodiment, the presenter communicates with the trusted party 

15 and the acceptor over the Internet. Another aspect of the invention pertains to a system for 
implementing the method for validating the profile data of the presenter. 

Another aspect of the invention pertains to a method for providing profile data of the 
presenter during an on-line transaction. This method involves querying a trusted party for 
profile data and providing the profile data to the acceptor by the trusted party. Another aspect 
20 of the invention pertains to a system for implementing the method for providing the profile 
data. 

These and other features and advantages of the present invention will be presented in 
more detail in the following specification of the invention and the accompanying figures, 
which illustrate by way of example the principles of the invention. 

25 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The invention, together with further advantages thereof, may best be understood by 
reference to the following description taken in conjunction with the accompanying drawings 
in which: 

5 FIG. 1 shows a system architecture and the message flows for the data authentication 

services system according to one embodiment of the present invention. 

FIG. 2 illustrates a flow diagram that describes the data authentication services process 
according to one embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

The present invention will now be described in detail with reference to a few preferred 
embodiments as illustrated in the accompanying drawings. In the following description, 
numerous specific details are set forth in order to provide a thorough understanding of the 
5 present invention. It will be apparent, however, to one skilled in the art, that the present 
invention may be practiced without some or all of these specific details. In other instances, 
well known operations have not been described in detail so not to unnecessarily obscure the 
present invention. 

The present invention provides methods and systems for authenticating the identity 
10 and validating the profile data of an individual ("a presenter") who presents him or herself to 
another party ("an acceptor") as having a certain identity and having certain corresponding 
profile data. The acceptor can be a service provider, a government agency, a merchant, or any 
other entity that may need to authenticate the identity of the presenter before proceeding with 
a transaction. Authentication of identity refers to verifying the identity of a presenting party 
15 who purports to be a certain individual. Validating profile data pertains to validating that 
profile data provided by a presenter actually is associated with the presenter. Other 
capabilities such as profile data provisioning and profile updating can also be performed. 
These functions can be performed individually or in any combination with each other. 

The invention can be advantageously used in Internet transactions where such 
20 authentication is difficult to perform. For instance, a presenter who is visiting a government 
website to gain access to government services may have to be authenticated beforehand by 
techniques of the present invention. In one embodiment, a trusted party interacts with the 
presenter to perform the authentication and then informs the acceptor as to authentication 
results. The techniques of the present invention allow the trusted party to give a definitive 
25 answer regarding the authenticity of identity. 

SYSTEM COMPONENTS 

FIG. 1 shows a system architecture and the message flows for the data authentication 
services system 700 according to one embodiment of the present invention. The system 
30 architecture aspect of FIG. 1 will be described in this section while the message flows, which 
describe the authentication process in more detail, will be described later in tandem with FIG. 
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2. The present invention can be used during online transactions, such as those that occur over 
the Internet. 

The systems and message flows of the present invention are based upon and are 
similar to the system and message flows described in U.S. Patent Application No. 09/842,313 
5 (Attorney Docket No. VISAP064), U.S. Patent Application No. 10/156,271 (Attorney Docket 
No. VISAP064C1), and U.S. Patent Application No. 10/370,149 (Attorney Docket No. 
VISAP070). 

Data authentication services system 700 includes a presenter domain 702, an 
interoperability domain 704, and an acquirer domain 706. Within presenter domain 702 is a 

10 presenter 708, trusted party 710, and an access control server 712 maintained by trusted party 
710, and a presenter file database 722. Presenter 708 is the user, individual, or consumer 
whose identity is being authenticated and whose data is being validated or provisioned. 
Presenter 708 can access system 700 using a variety of systems that range from super 
computers to mobile devices, such as cellular phones. Trusted party 710 is the entity that 

15 authenticates the identity and validates, provisions, or updates data relating to presenter 708. 
Trusted party 710 has an established relationship with presenter 708 and therefore has a 
reliable set of the presenter's profile data prior to a transaction that requires data services. For 
example, trusted party 710 can be a bank, a credit or debit card issuing bank, or a credit or 
debit card service organization (e.g., Visa). For example, this bank can be the issuing bank of 

20 a credit card that is used by this presenter. Presenter 708 can be a customer of this bank. As 
in this specific example, the relationship between presenter 708 and trusted party 710 usually 
is such that it can be trusted that the profile information relating to presenter 708 is accurately 
held by trusted party 710. 

Access control server (ACS) 712 is a computer system that controls access to the data 
25 authentication services program, performs the requested data services, and provides digitally 
signed notifications to acceptors regarding the data services. 

Presenter file database 722 is a database managed by the trusted party 710 that stores 
information relating to the presenters that are successfully enrolled in the data authentication 
services program. Such information includes program identity numbers, profile data, and 
30 passwords. 

Within interoperability domain 704 is a directory server 714 and a transaction history 

server 720. Interoperability domain 704 includes components used by both the trusted party 

and the acceptor. Directory server 714 facilitates the process of determining whether a 
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presenter 708 can utilize the data authentication services of the present invention. In many 
embodiments, directory server 714 will also route data authentication requests from acceptors 
716 to specific ACS's 712. Directory server 714 can be operated by a service organization 
such as Visa. When the network maintained by Visa supports system 700, directory server 
5 714 is referred to as the "Visa directory server." Transaction History Server 720 performs 
administrative functions that maintains records for supporting services such as billing, 
reporting, and dispute handling. In one embodiment, the Internet supports interoperability 
domain 704. 

Finally, within acceptor domain 706 is an acceptor 716, which incorporates an 
10 acceptor server plug-in (ASPI) 718. Acceptor 716 is a service provider, a government agency, 
a merchant, or any other party participating in data authentication services system 700 in order 
to use the services provided by system 700. ASPI 718 is software utilized by acceptor 716 to 
interface with the other components of data authentication services system 700. 

The respective relationship between presenter 708, trusted party 710, and acceptor 716 
15 within data authentication services system 700 allows a wide range of possible services to be 
provided. Some of the various data services include: identity authentication, profile 
validation, profile data provisioning, and profile data updating. One implementation of profile 
validation operates to validate the address of a presenter and one implementation of profile 
data updating operates to update the account information of a presenter. 

20 System 700 can be used in non-payment and in payment related transactions between 

presenter 708 and acceptor 706. In payment related transactions, additional operations such as 
authorization of debits and credits from financial accounts are also required. Additional 
systems such as issuer authorization and settlement systems are also required. 



25 PRESENTER ENROLLMENT PROCESS 

A presenter registers with a trusted party to be eligible to use the data authentication 
services program. Upon successful registration, a trusted party provides a presenter with a 
program identity number and an authenticating password, token, or other authenticating 
mechanism. A program identity number is a number that identifies presenters who are 
30 properly enrolled to use the authentication services program. A program identity number can 
be any type of number such as a random number or a number issued out of a series of 
numbers. In one embodiment of the invention, the program identity number can also be a 
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payment card number. This is convenient in the case where presenter 708 is a payment card 
cardholder and trusted party 710 is the issuing bank of the payment card. An authenticating 
password, token, or other authenticating mechanism allows trusted party 710 to authenticate 
the identity of a presenter 708 since only trusted party 710 and presenter 708 know the 
5 password, token, or other authenticating mechanism. 

During the enrollment process, the presenter should present the trusted party with 
enrollment data, authentication data, and profile data. Enrollment data is required to verify the 
presenter's identity so that the trusted party can be assured that the correct person is being 
enrolled as an eligible and participating presenter. Authentication data will be required to 

10 authenticate the presenter during a subsequent transaction using the techniques of the present 
invention. Examples of authentication data include passwords, chip cards, biometrics, etc. It 
should be understood that the various types of authentication data as discussed in this 
document can be interchangeably utilized. If not already on file with the trusted party, profile 
data will be required to validate and/or provision profile data during a subsequent transaction 

15 using the techniques of the present invention. 

The presenter enrollment process can occur in a variety of manners. For instance, the 
enrollment process can take place online, in a person-to-person interaction, a telephone 
conversation, or through the mail. An online enrollment process can involve a presenter who 
visits an enrollment website to provide the necessary information to obtain a program identity 
20 number and an authenticating mechanism. 



DATA AUTHENTICATION SERVICES TRANSACTION 

FIGS. 1 and 2 will now be described in tandem to describe the process for 
authenticating data according to one embodiment of the present invention. The data 
25 authentication services are provided through the "data authentication services program." FIG. 
2 describes a flow diagram 600 from a high-level point of view and FIG. 1 describes the 
specific message flows that occur simultaneously. As mentioned earlier, FIG. 1 shows the 
message flows on top of the system architecture 700. 

The data authentication services program can be used in a variety of situations where 
30 an acceptor desires to authenticate information presented by a presenter. For instance, in one 
of the situations a presenter can visit a government website (which is the acceptor website) in 
order to fill out an application for a small business license. Various government agencies 
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offer online services through their websites, which help reduce operation costs and provide 
citizens with increased accessibility to government services. Typically, a government agency 
desires to confirm the information entered by the individual (a presenter), such as name, name 
of business, address, and the like. The following example, described through FIGS. 1 and 4, 
5 describe operation of the data authentication services program through the situation where a 
potential customer applies for car insurance by visiting a website of a car insurance provider. 

FIG. 2 begins at block 602 when a presenter visits a website of an acceptor. Block 602 
is represented as step "a" in FIG. 1. To apply for such insurance coverage, the potential 
customer or presenter 708 visits the car insurance provider or acceptor 716 website to fill out 
10 an application form. Such an application form may request a wide range of data relating to 
car insurance policies. For example, the application form can request data such as name, 
address, birth date, driver's license data, make, model, and year of vehicle, current insurance 
status and terms, current insurance provider, policy terms desired, traffic violation history, and 
the like. In this example, trusted party 710 is a bank of which presenter 708 is a customer. 

15 Acceptor 716 desires to authenticate the information supplied in the application form 

so that acceptor 716 can properly provide a price quote or determine whether to offer an 
insurance policy to presenter 708, what terms to offer to presenter 708, and various other 
matters. 

If presenter 708 desires to use the authentication services program, then presenter 708 
20 enters his or her program identity number. Presenter 708 supplies his or her program identity 
number to acceptor 716 at the same time presenter 708 fills out the form. 

In block 604, acceptor checks to see if presenter is participating in "the data 
authentication services program." In one implementation, checking the participation status of 
a presenter is a two-phase process wherein directory 714 and then an access control server 712 

25 are queried. Directory server 714 determines if the trusted party 710 with whom presenter 
708 has a trusted relationship is participating within the data authentication services program. 
A presenter can use the data authentication services program only if a trusted party is willing 
to authenticate the identity of the presenter and to provide data services relating to the 
presenter. Then ACS 712 determines if the specific presenter 708 is enrolled with the services 

30 program. 

These two-phases are broken into the individual steps 1-4 in FIG. 1. In FIG. 1, step 1 

shows that acceptor server plug-in (ASPI) 718 sends a "service enrollment request message," 

SEReq message, to directory server 714 to determine presenter's eligibility for the 
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authentication services program. The SEreq message specifies the particular services which 
acceptor 716 is requesting be performed on presenter 708. 

The SEReq message identifies the program identity number of presenter 708 and 
queries directory server 714 to verify that the program identity number is within a range of 
5 numbers associated with a trusted party that is participating with the data authentication 
services program. If the program identity number does not fall within a range of program 
identity numbers defined on directory server 714, then trusted party 710 and thereby presenter 
708 are not enrolled. In this case, acceptor 716 is notified that the program identity number is 
not enrolled and ASPI 718 returns control of the transaction back to acceptor 716. At this 
10 point, acceptor 716 can proceed with the transaction either by refusing further service to 
presenter 708 or by proceeding with the transaction in another manner. 

On the other hand, if the program identity number is determined to be within a range 
of program identity numbers present in directory server 714, then the second phase of the 
verification process begins. The second phase begins when the SEReq message is forwarded 

15 to an appropriate presenter access control server (ACS) 712 to determine whether the 
requested data services are available for presenter 708. Data authentication services are 
available for a specific presenter when a presenter's program identity number is enrolled with 
the data authentication services program. If the program identity number is not enrolled, then 
the data services are not available and the acceptor can determine how it would like to proceed 

20 with the transaction. When ACS 712 indicates that the program identity number is enrolled, 
the ACS via the directory server provides the ACS URL Internet address to ASPI 718. 

In another implementation, verifying that a presenter 702 is enrolled is performed by 
having ASPI 718 directly query the ACS without first querying the directory server. In yet 
another implementation, acceptor 716 has a cache memory containing the same information 
25 held at directory server 714. In this manner, acceptor can perform the first phase of the 
enrollment determination. In other words, ASPI 718 can use the cache memory to determine 
if a presenter's program identity number is within the range of program identity numbers in a 
directory server. The cache memory does not indicate if an ACS can provide service for a 
presenter nor does it identify the ACS. 

30 Multiple ACS's 712 can exist within the authentication system 700. Each ACS 712 

manages the authentication of certain presenters 708. For instance, an ACS 712 maintained 
by a certain presenter bank 710 may only be suitable for authenticating profile data supplied 
by presenters who are also customers of that specific presenter bank. 
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In step 3 after ACS 712 determines whether authentication services are available to the 
specific presenter 708, ACS 712 responds to directory 714 with a service enrollment response 
(SERes) message indicating the status of the presenter account and the availability of the 
specific services requested by acceptor 716. 

5 In step 4 directory 714 then forwards the SERes message to ASPI 718. When ASPI 

718 receives indication from the SERes message as to whether presenter 708 is enrolled and 
able to use data authentication services, acceptor 716 can determine how to proceed with the 
transaction with presenter 708. If presenter 708 is not enrolled or not able to use the services, 
then acceptor 716 can decide to either terminate the transaction with presenter 708 or to 
10 proceed with the transaction in some other manner without using the data authentication 
services. 

However, if presenter 708 is enrolled and able to use the services, then the transaction 
process proceeds to block 606 or 608 in FIG. 2. This corresponds to step 5 in FIG. 1. Block 
606 represents the processes wherein trusted party 710 authenticates profile data provided by 
15 presenter 708. Block 608 represents the processes wherein trusted party 710 authenticates the 
identity of presenter 708 and then provides specific profile data to acceptor 716. The 
following description describes block 606. 

The processes of block 606 breakout into steps 5 through 9 of FIG. 1. In steps 5 and 6, 
ASPI 718 sends a data authentication request message, a DAReq message, to the appropriate 

20 trusted party ACS 712 by sending the DAReq message to presenter 708 who then forwards the 
DAReq message to ACS 712. Step 5 represents the transmission of the DAReq message from 
acceptor 716 to presenter 708 and step 6 represents the transmission of the DAReq message 
from presenter 708 to ACS 712. The DAReq message includes the profile data provided by 
presenter 708. As described earlier, the program identity number was sent to ACS 712 as part 

25 of the SEReq message. Upon receipt of the DAReq message by ACS 710, ACS will have the 
profile data to perform authentication services. 

In the alternative block 608, which also breaks out into steps 5 through 9, DAReq 
message includes a list of data elements that acceptor 716 desires to be provided by trusted 
party 710. 

30 Step 7 represents the interaction and messages that are exchanged between presenter 

708 and ACS 712 when trusted party 710 desires to authenticate the identity and validate the 

profile data of presenter 708. For example, this interaction begins when trusted party 710 

sends a message to presenter 708 that informs presenter 708 that acceptor 716 desires trusted 
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party 710 to authenticate the profile data submitted by presenter 708. Trusted party 710 
indicates that presenter 708 should provide its authentication password (or token) to trusted 
party 710 so that trusted party 710 can proceed with the authentication process. The 
authentication password should have been established between presenter 708 and trusted party 
5 710 during the enrollment process. The authentication password allows trusted party 710 to 
confirm that the actual presenter 708 (and not an imposter) desires to have trusted party 710 
authenticate the profile data received by acceptor 716 in block 602 (step a). In other words, 
when a presenter 708 enters the proper password, authentication system 700 can confirm that 
the actual presenter 708, and not an imposter, entered his or her own profile data on the form 
10 provided at the acceptor's website. The use of a password allows for a trusted party to 
provide a definite answer with regards to the authenticity of the presenter's identity. In some 
embodiments, step 7 also involves asking presenter 708 for permission to validate or provision 
the presenter's profile data. 

If ACS 712 determines that presenter 708 provided the incorrect authentication 
15 password, ACS 712 can ask presenter to reenter the authentication password. If presenter 708 
is unable to enter the correct password, then ASPI 718 will be informed that the identity and 
profile data cannot be authenticated. However, if ACS 712 determines that the correct 
authentication password was provided, then ACS 712 performs the requested data services. 

Provision of the correct password (which correlates to the program identity number) 
20 allows authentication system 700 to authenticate the identity and validate the profile data of 
presenter 708. Identity authentication confirms the identity of the presenter while profile 
validation confirms that the profile data provided by presenter 708 to acceptor 716 actually 
corresponds to presenter 708. The ACS can authenticate each data element of the profile data 
individually. For instance, ACS 712 can provide an authentication determination regarding 
25 each of a name, address, birth date, and other such data. 

Profile validation verifies the accuracy of the profile data provided by presenter 708 to 
acceptor 716. For example, ACS 712 can verify if the correct data has been provided for each 
type of requested profile data by comparing the data to reference data already stored by trusted 
party 710. In one embodiment, profile validation is performed during a payment authorization 
30 process to verify the address of a presenter. Profile validation of address information is often 
referred to as an "address verification service." 

With the profile data provisioning service, ACS 712 provides profile data to acceptor 
716 so that presenter 708 doesn't have to go through the tedious steps of providing the data 
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him or herself in step a. This can be advantageous because the possibility of human error 
during the data entry process can be avoided and because it simplifies the steps that presenter 
708 must take in providing data to acceptor 716. In this situation, presenter 708 only provides 
identifying data and his or her program identity number. Acceptor 716 then requests trusted 
5 party 710 to authenticate the identity of presenter 708 and to provide profile data of presenter 
708. Then trusted party 710 informs presenter 708 that acceptor 716 requests that trusted 
party 710 provide it with the profile data of presenter 708. Trusted party 710 typically will 
also ask presenter 708 for permission to provide certain profile data of presenter 708 to 
acceptor 716. The ACS-provided profile data can be sent back to ASPI 718 through a data 
10 authentication response message as shown in step 8. 

Another data service supported by the data services system of the present invention is 
a profile data updating service. This service does not involve presenter 708 and no presenter 
identity authentication is performed. This service occurs in the scenario when an acceptor 
already has profile data of the presenter and desires to obtain updated profile data. One 

15 implementation of the profile data updating service, referred to as "an account updating 
service," involves sending an acceptor party updated account information from a trusted party. 
Account information pertains to data that identifies an account held by a presenter. For 
instance, an account number is account information that identifies a payment account (e.g., 
credit or debit card account) that a presenter uses to purchase goods and services. In one 

20 scenario, a payment card account of a presenter has expired and a new payment card account 
has been issued to the presenter. An acceptor requests updated account data from the trusted 
party and the trusted party sends the updated account data to the acceptor. 

Profile data correction service corrects errors in the profile data provided by a 
presenter. In some cases, a presenter enters profile data with typographical errors. In these 
25 cases, the data service can correct the typographical errors. 

ACS 712 can use various techniques for authenticating the identity of the presenter. 
The use of passwords as described above is just one of the possible techniques. Other 
techniques include public key infrastructure (PKI), chip cards, biometrics, and password lists. 

During the interaction of step 7, there may be additional exchange of messages 
30 between presenter 708 and trusted party 710 relating to privacy laws. For example, trusted 
party 710 may need to obtain the permission of presenter 708 to proceed with authenticating 
or provisioning of the profile data at issue. Profile data stored by ACS 712 will not be shown 
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to presenter 708 or acceptor 716 unless presenter 708 provides trusted party 710 with the 
correct password. 

In step 8, after the appropriate data services have been processed, ACS 712 formats a 
data authentication response message (DARes) with appropriate values and signs it with a 
5 digital signature. The DARes message is then sent to presenter 708. The DAres message 
includes the data requested by acceptor 716. This data can include indications as to the 
authenticity of identity, validity of profile data, or it can include provisioned data. 

In step 9, the DARes message is then forwarded from presenter 708 to ASPI 718. 
ASPI 718 then validates the digital signature of the DARes message. At this point acceptor 
10 716 finds out if presenter 708 supplied authentic and correct profile data. Acceptor 716 will 
then typically proceed with the transaction if such profile data is authentic and correct, as 
represented in block 610 of FIG. 2 and step b of FIG. 1. In the example provided, acceptor 
716, the car insurance provider can decide if it will provide an insurance price quote or a 
policy to presenter 708. 

15 In some embodiments, the DAReq and the DARes messages can be sent between ACS 

712 and ASPI 718 directly rather than through presenter 708. In one embodiment, the DAReq 
and DARes messages are sent to each other over the Internet. This is appropriate in instances 
when the data services are being used without presenter involvement, such as for a service that 
involves account data updating. 

20 It should be understood that all messages described in FIG. 1 can be encrypted to 

increase the level of security. 

The present invention can also be implemented when a presenter accesses the data 
authentication services program when using mobile devices. The processes and system of the 
present invention supports mobile devices that send messages over the Internet, voice 
25 channels, and text messaging channels. 

While this invention has been described in terms of several preferred embodiments, 
there are alteration, permutations, and equivalents, which fall within the scope of this 
invention. It should also be noted that there are many alternative ways of implementing the 
methods and apparatuses of the present invention. It is therefore intended that the following 
30 appended claims be interpreted as including all such alterations, permutations, and equivalents 
as fall within the true spirit and scope of the present invention. 
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